feat: GitHub Action annotations for failed builds#2
feat: GitHub Action annotations for failed builds#2dxmh wants to merge 1 commit intozmkfirmware:mainfrom
Conversation
|
After some conversations on Discord back in December, I started to move this work into a script that could reside in the main ZMK firmware repo (and executed via Github Actions), so that
Unfortunately I didn't get a chance to complete this work, but I thought it would be worth sharing my initial progress here for future reference: dxmh/zmk@3ad9c44 |
|
|
#4 is awesome. In the scope of this PR (#2), I understand that once #4 has been rolled out, there will no longer be the issue of needing to update files in users I do think the parsing and output of hints/annotations would be best done by a more complete script (be it shell/python/etc) – it would be easier to maintain and test, and has the benefit of local usage. But if we wanted to get the GH Annotations to users sooner rather than later, a step like the one added in this PR (#2) could be easily added "in-workflow" once #4 lands, and easily swapped out to execute a script later down the line. |
2 participants
To try and make the GitHub build experience more user-friendly, I've added a step to the workflow to produce annotations when
west buildfails. These annotations are shown on the page where a user would go to download their firmware.A failure will produce a notice informing the user the build has failed and where they can find help:
Additionally, I've included annotations to help with what I believe to be the top 3 most common issues users have on the ZMK Discord server. We can add additional annotations as and when necessary.
Annotation for errors due to incorrect keycodes:
e.g.
&kp SLSHinstead of&kp SLASHError message in log:
Annotation for errors due to incorrect phandle references:
e.g.
&kc ENTERinstead of&kp ENTERError message in log:
Annotation for errors due to missing parameters:
e.g.
&mt LALTinstead of&mt LALT FError message in log:
I have a couple of thoughts:
Instead of having all of this inside of
workflows/build.yml, we could call a shell script. This would not only keep the yaml file leaner but it would make it easier to test the parsing locally.We could include an error codes for each unique annotation we seek out? For example, errors due to incorrect keycodes such as
&kp ENTREcould be prefixed withE101. We could then write about them in more detail on https://zmk.dev/docs/troubleshooting/.I'm not sure if these need to be solved now or if they can wait until later.
Please let me know what you think!